Data link/physical layer packet buffering and flushing

ABSTRACT

A buffering structure including at least a first FIFO storage structure to stage at least a selected one of undiverted egress packets and undiverted ingress packets is provided. The buffering structure further includes at least first associated packet drop logic to selectively effectuate head or tail flushes of the first FIFO storage structure. In various embodiments, one or more additional FIFO storage structures are also provided to stage one or more diverted and/or insertion of egress/ingress packets. Those use for staging diverted egress/ingress packets are likewise provided with associated packet drop logic to perform tail flushes of these additional FIFO structures. In one application, the buffering structure is employed by a multi-protocol network processor, which in turn is employed by an optical networking module.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of networking. Morespecifically, the present invention relates to packet buffering andflushing for high-speed network trafficking equipment, such as10-gigabit optical-electrical routers or switches.

2. Background Information

With advances in integrated circuit, microprocessor, networking andcommunication technologies, increasing number of devices, in particular,digital computing devices, are being networked together. Devices areoften first coupled to a local area network, such as an Ethernet basedoffice/home network. In turn, the local area networks are interconnectedtogether through wide area networks, such as SONET networks, ATMnetworks, Frame Relay, and the like. Of particular importance is theTCP/IP based global inter-network, the Internet.

As a result of this trend of increased connectivity, increasing numberof applications that are network dependent are being deployed. Examplesof these network dependent applications include but are not limited to,the World Wide Web, e-mail, Internet based telephony, and various typesof e-commerce and enterprise applications. The success of manycontent/service providers as well as commerce sites depend on high-speeddelivery of a large volume of data across wide areas. In turn, the trendleads to increased demand for high-speed data trafficking.

Historically, data communication protocols specified the requirements oflocal/regional area networks, whereas telecommunication protocolsspecified the requirements of the regional/wide area networks. The rapidgrowth of high volume, high-speed data routing over the Internet hasfueled a convergence of data communication (datacom) andtelecommunication (telecom) protocols and requirements. It isincreasingly important that data traffic be carried efficiently at highspeed across local, regional and wide area networks.

When routing or switching network traffic, a need often arises to divertsome of the packets being routed/switched onto a routing path (toperform additional processing or dropping the packets), or insertadditional packets into the packet streams being received off a routingpath. FIG. 1 illustrates a typical prior art approach to providing suchfunctionality of packet diversion and/or packet insertion to an“intermediate” networking equipment. Illustrated is an examplenetworking switch/router 50 having switching/routing fabric 52,including a number of ingress/egress points 54 a-54 n, through whichpackets may be received and/or routed onto the corresponding coupledmediums (routing paths). To provide the desired packet diversion and/orinsertion functionality, one or more of ingress/egress points 54 a-54 n,such as point 54 n, are reserved for the coupling of one or morecompanion processors 56 (also referred to as host processors), asopposed to the mediums connecting the switch/router to a network. Thebasic implementations of these switches/routers would route all packetsthrough host processors 56, to enable host processors 56 to selectivelydivert some of the packets from the various routing paths (foradditional processing or dropping the packets) or to selectively injectadditional packets into the packet streams of the various routing paths.In other more advanced implementations, additional switching/routingresources (such as programmable switching/routing tables) (not shown)may be employed to facilitate routing of some of the packets of therouting paths to host processors 56 for “processing” (“diversion”), androuting of the packets injected by host processors 56 onto the routingpaths of their selection (“insertion”).

These prior art approaches all suffer from the common disadvantage inthat at least one of the ingress/egress point of switching/routingfabric 52 is used for the coupling of a host processor 56. As networkingspeed increases, with more and more packets being routed/switched over aunit of time, host processor 56 becomes a bottleneck under these priorart approaches. Typically, more than one host processor 56 have to beemployed, resulting in more than one ingress/egress points 54 a-54 nbeing consumed, which in turn leads to a reduction in the bandwidth ofnetworking equipment 50 (for a given amount of switching/routingresources (fabric 52)). Increasingly, these architectures are becomingun-scalable for the type of efficient, high speed (10 Gb and beyond)networking that spans local, regional, and wide area networks,especially when multiple datacom and telecom protocols are involved.

Thus, an improved approach to packet diversion and insertion, includingbuffering and flushing of buffered packets, is desired.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will be described by way of exemplary embodiments,but not limitations, illustrated in the accompanying drawings in whichlike references denote similar elements, and in which:

FIG. 1 illustrates a typical prior art approach to providing packetdiversion and insertion;

FIG. 2 illustrates an overview of the data link/physical layer packetdiversion and insertion of present invention, in accordance with oneembodiment;

FIG. 3 illustrates the buffering structure of FIG. 2 in further detail,in accordance with one embodiment;

FIG. 4 illustrates the egress divert block of FIG. 3 in further detail,including write packet drop logics equipped with tail flushingcapability for multiple datacom and telecom protocols, in accordancewith one embodiment;

FIG. 5 illustrates the egress insert block of FIG. 3 in further detail,including read packet drop logics equipped with head flushing capabilityfor multiple datacom and telecom protocols, in accordance with oneembodiment;

FIG. 6 illustrates the register interface of FIG. 3 in further detail,in accordance with one embodiment;

FIG. 7 illustrates the ingress divert block of FIG. 3 in further detail,including write packet drop logics equipped with tail flushingcapability for multiple datacom and telecom protocols, in accordancewith one embodiment;

FIG. 8 illustrates the ingress insert block of FIG. 3 in further detail,including read packet drop logics equipped with head flushing capabilityfor multiple datacom and telecom protocols, in accordance with oneembodiment;

FIG. 9 illustrates a multi-protocol network processor incorporated withthe present invention, in accordance with one example application; and

FIG. 10 illustrates an optical networking module incorporated with themulti-protocol processor of FIG. 9, in accordance with another exampleapplication. GLOSSARY 10Gbase-LR 64/66 coded 1310 nm LAN standard for 10Gigabit Ethernet 10Gbase-LW 64/66 coded SONET encapsulated 1310 nm WANstandard for 10 Gigabit Ethernet ASIC Application Specific IntegratedCircuit CRC Cyclic Redundancy Check Egress Outgoing data path from thesystem to the network EOP End of Packet EOS Ethernet on SONET FCS FrameCheck Sequence FIFO First In First Out HDLC High-level Data LinkControl. A communication protocol used in Packet over SONET switchingnetwork. Ingress Incoming data path from the network to the system IPInternet Protocol LAN Local Area Network LVDS Low voltage differentialsignal MAC Media Access Control layer, defined for Ethernet systems OIFOptical Internetworking Forum POS Packet over SONET PPP Point to PointProtocol SDH Synchronous Digital Hierarchy SONET Synchronous Opticalnetwork, a PHY telecommunication protocol SOP Start of Packet SPI-4System Packet Interface Level 4(also POS-PHY 4) SSTL Stub SeriesTerminated Logic XGMII 10 Gb Media Independent Interface WAN Wide AreaNetwork

DETAILED DESCRIPTION OF THE INVENTION

The present invention includes a buffering structure having storagestructures and associated packet diversion and insertion logic tofacilitate post-switching, pre-medium placement diversion and/orinsertion of egress packets, and/or post-medium extraction,pre-switching diversion and/or insertion of ingress packets, inparticular, during data link/physical layer processing of the ingressand/or egress packets. In another aspect, the buffering structurefurther includes selective tail and head flushing of the bufferedpackets. Both aspects address support for multiple datacom and telecomprotocols.

In the following description, various aspects of the present inventionwill be described. However, the present invention may be practiced withonly some aspects of the present invention. For purposes of explanation,specific numbers, materials and configurations are set forth in order toprovide a thorough understanding of the present invention. However, thepresent invention may be practiced without the specific details. Inother instances, well-known features are omitted or simplified in ordernot to obscure the present invention. Further, the descriptionrepeatedly uses the phrase “in one embodiment”, which ordinarily doesnot refer to the same embodiment, although it may. The terms“comprising”, “having”, “including” and the like, as used in the presentapplication, including in the claims, are synonymous.

Overview

Referring now to FIG. 2, wherein a block diagram illustrating anoverview of the present invention, in accordance with one embodiment, isshown. As illustrated, networking switch/router 60 havingswitching/routing fabric 62, including ingress/egress points 64 a-64 n,through which packets may be received and/or routed onto thecorresponding coupled mediums (routing paths), in accordance with thepresent invention, is provided with a number of buffering structures 100a-100 n to facilitate packet diversion and insertion, includingselective tail or head flushing of buffered packets, for multipledatacom and telecom protocols. Buffering structures 100 a-100 n inaccordance with the present invention are disposed betweeningress/egress points 64 a-64 n and the corresponding mediums couplingswitch/router 60 to one or more networks. As will be described in moredetail below, each of buffering structures 100 a-100 n includes a numberof storage structures, associated packet diversion and insertion logic,including packet flushing logic, as well as a processor interface toallow processors 66 to direct the diversion of packets, access thediverted packets, as well as inject packets for egress and/or ingresspackets. Each of buffering structures 100 a-100 n also allows selectivehead or tail flushing of buffered packets. As a result of thesefeatures, and its advantageous disposition, buffering structures 100a-100 are able to facilitate post-switching, pre-medium placement,diversion and/or insertion of egress packets, as well as post-mediumextraction, pre-switching, diversion and/or insertion of ingress packetsfor multiple datacom and telecom protocols.

As is readily apparent from the illustration, unlike the prior art, thepresent invention is able to facilitate the packet diversion andinsertion functionalities without taking up ingress/egress points 64a-64 n of switching/routing fabric 62, and therefore, bandwidth ofswitch/router 60. Moreover, the diversion and insertion of egresspackets may be performed “very late”, just prior to placement of thepackets onto the coupling mediums, e.g. during data link/physical layerprocessing of the egress packets, and likewise, the diversion andinsertion of ingress packets may be performed “very early”, as soon asextraction of the packets from the coupling mediums, e.g. during datalink/physical layer processing of the ingress packets. Accordingly, in apresently preferred embodiment, as illustrated by an exemplaryapplication of the present invention to be described later (referencingFIG. 9-10), buffering structures 100 a-100 n are advantageously providedas an integral part of the ASICs that provide data link/physical layerprocessing for multiple datacom and telecom protocols, in particular, inan integrated optical networking module.

Buffering Structure

FIG. 3 illustrates one of buffering structures 100 a-100 n of FIG. 2 infurther details in accordance with one embodiment. As illustrated, forthe embodiment, buffering structure 100 i includes a number of egresspacket storage structures 102 a-102 c, egress packet divert logic 104and egress packet insert logic 106. Egress packet storage structures 102a-102 c includes egress undiverted packet storage structure 102 a,egress diverted packet storage structure 102 b, and egress insert packetstorage structure 102 c, employed to stage the egress undivertedpackets, egress diverted packets, and egress insert packetsrespectively. Egress packet divert logic 104 is employed to selectivelydivert some of the egress packets to the diversion path, i.e. egressdiverted packet storage structure 102 b, whereas egress insert logic 106is employed to selectively merge the staged egress insert packets ontothe transmit path, i.e. merging the egress undiverted and insert packetsstaged at storage structures 102 a and 102 c.

For the embodiment, buffering structure 100 i further includes a numberof ingress packet storage structures 122 a-122 c, ingress packet divertlogic 124, ingress packet insert logic 126, and in particular, processorinterface 112. Ingress packet storage structures 122 a-122 c includesingress undiverted packet storage structure 122 a, ingress divertedpacket storage structure 122 b, and ingress insert packet storagestructure 122 c, employed to stage the ingress undiverted packets,ingress diverted packets, and ingress insert packets respectively.Ingress packet divert logic 124 is employed to selectively divert someof the ingress packets to the diversion path, i.e. ingress divertstorage structure 122 b, whereas ingress packet insert logic 126 isemployed to selectively merge the staged ingress insert packets onto thereceive path, i.e. merging the ingress undiverted and insert packetsstaged at storage structures 122 a and 122 c.

In one embodiment, storage structures 102 a-102 c and 122 a-122 c areFirst-In First-Outs (FIFO) storage structures; and processor interface112 is a register-based interface, accessible via a data bus orprocessor interface (not shown), and includes associated read and writepointers. More specifically, in one embodiment, the egress undivertedpacket FIFO 102 a has a size of 1536 word by 73 bits (64-bits for thepacket data, plus 4-bit SOP, 4-bit EOP and 1 bad packet bit indicator),and each of the egress diverted packet FIFO 102 b and egress insertpacket FIFO 102 c has a size of 64 words by 73 bits. Similarly, theingress undiverted packet FIFO 122 a has a size of 1536 word by 73 bits,and each of the ingress diverted packet FIFO 122 b and ingress insertpacket FIFO 122 c has a size of 64 words by 73 bits.

Before proceeding to describe the logic components, i.e. components104-106 and 124-126, in further detail, it should be noted that whilefor completeness, the embodiment is comprehensively illustrated toinclude facilities associated with packet diversion and packet insertionfor egress as well as ingress packets, in practice, the presentinvention may be practiced with only some of these features to practiceonly some of the aspects of the present invention, e.g. diversion ofegress packets only, insertion of egress packets only, diversion ofingress packets only, or insertion of ingress packets only, orcombination thereof.

Egress Diversion

Turning now to FIG. 4, wherein egress packet divert logic 104 of FIG. 3is illustrated in further details in accordance with one embodiment. Asshown, for the embodiment, egress packet divert logic 104 includesegress packet selector 132, egress undiverted packet gap compressionlogic 134, egress undiverted packet SS write and overflow packet droplogic 136, egress diverted packet gap compression logic 138, and egressdiverted packet SS write, overflow and drop logic 136.

Egress packet selector 132 is designed to receive the egress packetdata, including the associated SOP, EOP, and bad packet bits, as well asa number of control signals. The control signals include in particular,a first control signal denoting an egress packet is to be diverted, anda second control signal denoting an egress packet is to be dropped.Responsive to the assertion of the divert control signal, egress packetselector 132 routes the egress packet data being received to thediversion path (diverted packet storage structure 102 b); otherwise, thereceived egress packet data are allowed to pass thru onto the transmitpath (undiverted packet storage structure 102 a).

Each of the egress packet gap compression logic 134 and 138 removespacket data gaps for the corresponding data paths, i.e. transmit anddiversion paths. Further, each of egress packet gap compression logic134 and 138 generates a data ready signal for the correspondingfollowing storage structure's write, overflow and drop logic 136 and140, when a complete n-bit word of the egress packet is available (nbeing 64 in the earlier described FIFO embodiments).

Each of the write, overflow and drop logic 136 and 140, in response,generates a write enable signal for the corresponding storage structure102 a and 102 b, and writes the n-bit word, along with the SOP, EOP andbad packet indicator bit into one n-bit storage word of the storagestructure 102 a/102 b. Diverted packet write, overflow and drop logic140 also generates a signal to convey packet availability to the hostprocessor, when a complete packet is ready for the host processor toretrieve.

For the embodiment, each of write, overflow and drop logic 136 and 140is also responsible for flushing the corresponding storage structure,i.e. storage structure 102 a and 102 b, total or tail only, when acorresponding flushing bit (specified e.g. in a configuration register(not shown)) is set.

For the earlier described FIFO embodiments, total flushing of FIFO 102a/102 b may be accomplished by synchronously resetting both theassociated write and read pointers (not shown) of the FIFO to zero.

Further, for the embodiment, each of write, overflow and drop logic 136and 140 is responsible for packet dropping from the “tail” of thecorresponding storage structure 102 a and 102 b (“tail flushing”). Forthe embodiment, each of write, overflow and drop logic 136 and 140initiates the tail packet dropping/flushing process if one of a numberof conditions occurs. Examples of these conditions include but are notlimited to

-   -   a) Storage structure overflow caused by an attempted write into        a full storage structure; and    -   b) In response to the earlier mentioned packet drop control        signal.

For the earlier described FIFO embodiments, for the former cause(condition (a)), logic 136/140 reloads the associated write pointer tothe SOP location of the packet being dropped+2, and writing an EOPcondition into the SOP+2 location, with the bad packet bit set. Further,the residual truncated packet is invalidated by the corresponding read,underflow and drop logic 142/144 of egress insert logic 106. This mannerof tail flushing is performed except while operating for packetstransmitted in accordance with the HDLC and SONET protocols.

In one embodiment, in support of packets transmitted in accordance withthe HDLC and SONET protocols, logic 136/140 also accounts for thepossibility that the SOP has already been read out of storage structure102 a/102 b, during an overflow situation. More specifically, for theearlier described FIFO embodiments, logic 136/140 reloads the writepointer with the read pointer address plus 8. Logic 136/140 then writesthe EOP at this location, with the bad packet bit set, which results ina partial flush of the bad packet. The bad packet flag in turn will alsoalert a downstream MAC or HDLC processor that the preceding packet wasaborted. In one embodiment, the MAC or HDLC processor responds bycorrupting the CRC of the truncated packet to guarantee that the packetbe dropped by a downstream entity.

For the earlier described FIFO embodiments, for the latter cause(condition (b)), logic 136/140 also takes into account whether SOP ofthe aborted packet is still in the corresponding FIFO 102 a/102 b. Ifthe SOP of the aborted packet is still in the FIFO, and if the SOPaddress is 6 greater than the read pointer address, upon detecting thepacket drop signal, logic 136/140 reloads the FIFO write pointer withthe abort packet's SOP address plus 2, and then writes the EOP to thislocation, with the bad packet bit set. Again, the residual partialpacket is invalidated by the corresponding read, underflow and droplogic 142/144 of egress insert logic 106. If the SOP of the abortedpacket is still in the FIFO, and if the SOP address is less than 6larger than the read pointer address, the EOP and bad packet bit iswritten to the read point address plus 8 to insure the read pointer willnot advance past the write pointer and miss the EOP and bad packet bit,and cause the pointers to get out of sequence. The corresponding FIFOread, underflow and drop logic 142/144 of egress insert logic 106 isemployed to invalidate the byte containing the EOP. If on the otherhand, the SOP of the aborted packet has already been read out of theFIFO, logic 106 will reload the FIFO write pointer with the read pointeraddress plus 8. Logic 106 then writes the EOP at this location, with thebad packet bit set, resulting in a partial flush of the bad packet.Again, the bad packet flag will be detected by the corresponding read,underflow and drop logic 142/144 of egress insert logic 106.

In one embodiment, in support of packets transmitted in accordance withthe EOS protocol, write, overflow and drop logic 136/140 is alsodesigned to generate the byte count of an EOS data packet (during an EOSmode of operation), to facilitate subsequent insertion of the packetbyte length into a 2-byte field after the preamble, during framegeneration for EOS. In one embodiment, an additional 16-bit wide,40-word deep FIFO (not shown) is employed to store the generated EOSpacket sizes.

Egress Insertion

FIG. 5 illustrates egress packet insert logic 106 of FIG. 3 in furtherdetails in accordance with one embodiment. As illustrated, for theembodiment, egress packet insertion logic 106 includes egress undivertedpacket SS read, underflow and drop logic 142, egress inserted packet SSread and path access logic 144, and egress packet merge logic 146.

Egress packet merge logic 146 is employed to generate a read enablesignal for either read, underflow and drop logic 142 and 144 to selectegress packets stored in one of the two storage structures 102 a and 102c.

Read, underflow and drop logic 142 is responsible for generating theread enable signal in response for the selection of storage structure102 a, to enable data flow from storage structure 102 a.

Read, underflow and drop logic 142 is also responsible for flushing thecorresponding storage structure 102 a, total or head only. For theearlier described FIFO embodiments, total flushing may be accomplished,as described earlier, by synchronously resetting both the write and readpointers to zero. No additional data words, of the current packet, willbe written to the FIFO until a new SOP is received. Read, underflow anddrop logic 142 will refrain from initiating any reading of thecorresponding FIFO, until the FIFO word count of the corresponding FIFOexceeds a predetermined threshold.

Read, underflow and drop logic 142 is also responsible for packetdropping from the “head” of the corresponding storage structure. In oneembodiment, read, underflow and drop logic 142 performs the “head”packet drop/flush in response to a number of predetermined conditions.Examples of these conditions include but are not limited to

-   -   a) Egress datapath underflow caused by an attempted read of an        empty storage structure; and    -   b) In response to a packet drop control signal.

For the earlier described FIFO embodiments, for the earlier condition(i.e. condition (a)), read, underflow and drop logic 142 performs the“head” drop/flush by muxing an EOP into the data path. The actionconveys to any subsequent (data link/physical layer) processing unit,e.g. a MAC or HDLC processor, that the current packet is bad. In oneembodiment, the MAC or HDLC processor responds by corrupting the CRC ofthe current packet.

As described earlier, total flushing of the corresponding FIFO may beperformed by synchronously resetting both the write and read pointers tozero. No additional data words, of the current packet, will be writteninto the corresponding FIFO, until a new SOP is received.Correspondingly, no reading of the FIFO on the output side will beinitiated either, until the FIFO word count has reached a predeterminedthreshold.

For the earlier described FIFO embodiments, for the latter condition(i.e. condition (b)), read, underflow and drop logic 142 determines ifthe SOP of the aborted packet is still in the process of being read outin the output side, when the EOP and bad packet bit are detected. If so,the remaining words of the truncated packet are invalidated. Thus, uponcompleting the dropping of the rest of the aborted packet on the writeside, dropping of the current packet is effectuated.

If the SOP has already been read out, the EOP byte of the current wordis invalidated. The action will notify subsequent processing units, suchas MAC or HDLC processors, that the current packet is bad. Again, in oneembodiment, the MAC or HDLC processor responds by corrupting the CRC ofthe current packet.

In like manner, read and path access logic 144 is responsible forgenerating the read enable signal in response for the selection ofstorage structure 102 c, to enable data flow from storage structure 102c. Read and path access logic 144 is also responsible for notifying thehost processor that it may provide additional insert data when storagestructure 102 c becomes empty.

Processor Interface—Egress Packet Side

FIG. 6 illustrates processor interface 112 of FIG. 3 in further detailsin accordance with one embodiment. As illustrated, for the embodiment,for the egress packet side, processor interface 112 includes a number ofegress data read and write (R/W) registers, and their associatedprocessor control slave logic 156, egress diverted packet unpacker anddata formatter 152, and egress insert data packer and SOP/EOP generationlogic 154.

Egress data RAN registers, and their associated processor control slavelogic 156 are employed to facilitate a host processor in retrieving theegress diverted packet data, and providing the egress insert packetdata. In response to a notice of the egress diverted packet data beingready for the host processor to retrieve, the host processor generatesthe appropriate control signals for egress diverted packet unpacker anddata formatter 152 through the associated processor control slave logic156. Egress diverted packet unpacker and data formatter 152 in response,generates the appropriate read enable signals for the egress divertedpacket storage structure 102 b. Further, unpacker and data formatter 152reads the gap-compressed packet data and the associated SOP, EOP and badpacket indicator from storage structure 102 b, and “unpack” them forplacement onto the appropriate bit positions of the data bus. Theprocess continues until the EOP is encountered (i.e. the applicable EOPbit set).

In like manner, a host processor generates the appropriate controlsignals for egress insert data packer and SOP/EOP generation 154 throughthe associated processor control slave logic 156. Egress insert datapacker and SOP/EOP generation 154 in response, generates the appropriatewrite enable signals for the egress insert storage structure 102 c.Further, data packer and SOP/EOP generation 154 writes the insert dataand the associated SOP, EOP and bad packet indicator bits into storagestructure 102 c in “packed” form, and the unpacked portions aresuccessively taken off the appropriate bit positions of the data bus.

Ingress Diversion

FIG. 7 illustrates ingress packet divert logic 124 of FIG. 3 in furtherdetails in accordance with one embodiment. As illustrated, for theembodiment, ingress packet divert logic 124 includes ingress packetselector 162, ingress undiverted packet gap compression logic 164,ingress undiverted packet SS write, overflow and drop logic 166, ingressdiverted packet gap compression logic 168, ingress diverted packet SSwrite, overflow and drop logic 170.

Ingress packet selector 162 is designed to receive the packet data,including the associated SOP, EOP, and bad packet bits, as well as anumber of control signals. The control signals include in particular, afirst control signal denoting an ingress packet is to be diverted, and asecond control signal denoting an ingress packet is to be dropped.Responsive to the assertion of the control signal denoting an ingresspacket is to be diverted, ingress packet selector 132 routes the ingresspacket data being received to the diversion path (diverted packetstorage structure 122 b); otherwise, the received ingress packet dataare allowed to pass thru onto the receive path (undiverted packetstorage structure 122 a).

Each of the ingress packet gap compression logic 164 and 168 removespacket data gaps for the corresponding data paths, i.e. receive anddiversion paths. Further, each of ingress packet gap compression logic164 and 168 generates a data ready signal for the correspondingfollowing storage structure's write, overflow and drop logic 166 and170, when a complete n-bit word is available (n being 64 in the earlierdescribed FIFO embodiments).

Each of the write, overflow and drop logic 166 and 170, in response,generates a write enable signal for the corresponding storage structure122 a and 122 b, and writes the n-bit word, along with the SOP, EOP andbad packet indicator bit into one n-bit storage word. Diverted packetwrite, overflow and drop logic 170 also generates a signal to conveypacket availability to a host processor, when a complete ingress packetis ready for the host processor to retrieve.

For the embodiment, each of write, overflow and drop logic 166 and 170is also responsible for flushing the corresponding storage structure,i.e. storage structure 122 a and 122 b (total or tail only), when acorresponding flushing bit (specified e.g. in a configuration register(not shown)) is set.

For the earlier described FIFO embodiments, total flushing FIFO 122a/122 b may be accomplished by synchronously resetting both theassociated write and read pointers of the FIFO to zero.

Further, for the embodiment, each of write, overflow and drop logic 166and 170 is responsible for packet dropping from the “tail” of thecorresponding storage structure 122 a and 122 b. For the embodiment,each of write, overflow and drop logic 166 and 170 initiates the packetdropping process if one of a number of conditions occurs. Examples ofthese conditions include but are not limited to

-   -   a) Storage structure overflow caused by an attempted write into        a full storage structure; and    -   b) In response to the earlier mentioned packet drop control        signal.

For the earlier described FIFO embodiments, for the former cause(condition (a)), logic 166/170 reloads the associated write pointer tothe SOP location of the packet being dropped+2, and writing an EOPcondition into the SOP+2 location, with the bad packet bit set. Further,the residual truncated packet is invalidated by the corresponding read,underflow and drop/path access logic 172/174 of ingress insert logic126. This manner of tailing flushing is performed except when operatingfor packets transmitted in accordance with the HDLC and SONET protocols.

In one embodiment, in support of packets transmitted in accordance withthe HDLC and SONET protocols, logic 166/170 also accounts for thepossibility that the SOP has already been read out of storage structure122 a/122 b by the downstream SPI-4 logic 204 (FIG. 9), during anoverflow situation. More specifically, for the earlier described FIFOembodiments, logic 166/170 reloads the write pointer with the readpointer address plus 8. Logic 166/170 then writes the EOP at thislocation, with the bad packet-bit set, which results in a partial flushof the bad packet. If the bad packet SOP has already been transferred tothe downstream SPI-4 logic 204, an abort indication is asserted to theSPI-4 logic 204, causing the SPI-4 logic 204 to abort the bad packettransfer.

For the earlier described FIFO embodiments, for the latter cause(condition (b), logic 166/170 also takes into account whether SOP of theaborted packet is still in the corresponding FIFO 122 a/122 b. If theSOP of the aborted packet is still in the FIFO, and if the SOP addressis 6 greater than the read pointer address, upon detecting the droppacket signal, logic 166/170 reloads the FIFO write pointer with theabort packet's SOP address plus 2, and then writes the EOP to thislocation, with the bad packet bit set. Again, the residual partialpacket is invalidated by the corresponding read, underflow and drop/pathaccess logic 172/174 of ingress insert logic 126. If the SOP of theaborted packet is still in the FIFO, and if the SOP address is less than6 larger than the read pointer address, the EOP and bad packet bit iswritten to the read point address plus 8 to insure the read pointer willnot advance pass the write pointer and miss the EOP and back packet bit,and cause the pointers to get out of sequence. The corresponding FIFOread, underflow and drop/path access logic 172/174 of ingress insertlogic 126 is employed to invalidate the byte containing the EOP. If onthe other hand, the SOP of the aborted packet has already been read outof the FIFO, logic 126 will reload the FIFO write pointer with the readpointer address plus 8. Logic 126 then writes the EOP at this location,with the bad packet bit set, resulting in a partial flush of the badpacket. Again, the bad packet flag will be detected by the correspondingread, underflow and drop/path access logic 172/174 of ingress insertlogic 126. If the bad packet SOP has already been read by the SPI-4logic 204, logic 126 signals an abort condition to the SPI-4 logic 204.This causes the SPI-4 logic 204 to abort the bad packet currently beingtransferred.

Ingress Insertion

FIG. 8 illustrates ingress insertion logic 126 of FIG. 3 in furtherdetails in accordance with one embodiment. As illustrated, for theembodiment, ingress insertion logic 126 includes ingress undivertedpacket read, underflow and drop logic 172, ingress inserted packet readand path access logic 174, and ingress packet merge logic 176.

Ingress packet merge logic 176 is employed to generate a read enablesignal for either read, underflow and drop logic 172 or read and accesspath logic 174 to select ingress packets stored in one of the twostorage structures 122 a and 122 c.

Read, underflow and drop logic 172 is responsible for generating a readenable signal, in response, for the selection of storage structure 172 ato enable data flow from the selected storage structure 172 a.

Read, underflow and drop logic 172 is also responsible for flushing thecorresponding storage structure 122 a (total or head only). For theearlier described FIFO embodiments, total flushing may be accomplished,as described earlier, by synchronously resetting both the write and readpointers to zero. No additional data words, of the current packet, willbe written into the ingress packet FIFO until a new SOP is received.Read, underflow and drop logic 172 will refrain from initiating anyreading of the corresponding FIFO, until the FIFO word count of thecorresponding FIFO exceeds a predetermined threshold.

Read, underflow and drop logic 172 is also responsible for packetdropping from the “head” of the corresponding storage structure 122 a.In one embodiment, read, underflow and drop logic 172 performs the“head” packet drop in response to a number of predetermined conditions.Examples of these conditions, include but are not limited to

-   -   a) Ingress datapath underflow caused by an attempted read of an        empty storage structure;    -   b) In response to a packet drop control signal.

For the earlier described FIFO embodiments, for the earlier condition(condition (a)), read, underflow and drop logic 172 performs the “head”drop by muxing an EOP into the data path. Additional, a control signalis generated for ingress packet merge 176 to forward the downstreamprocessing units, e.g. a coupled system, that the current packet is tobe dropped.

As described earlier, total flushing of the corresponding FIFO may beperformed by synchronously resetting both the write and read pointers tozero. No additional data words, of the current packet, will be writteninto the corresponding FIFO, until a new SOP is received. Corresponding,no reading of the FIFO on the output side will be initiated either,until the FIFO word count has reached a predetermined threshold.

For the earlier described FIFO embodiments, for the latter condition(condition (b)), read, underflow and drop logic 142 determines if theSOP of the aborted packet is still in the process of being read out inthe output side, when the EOP and bad packet bit are detected. If so,the remaining words of the truncated packet are invalidated. Thus, uponcompleting dropping the rest of the aborted packet on the write side,dropping of the current packet is effectuated.

If the SOP has already been read out, a control signal is generated foringress packet merge 176 to forward the downstream processing units,e.g. a coupled system, to denote for the downstream processing unitsthat the current packet is to be dropped.

In like manner, read and path access logic 174 is responsible forgenerating the read enable signal in response for the selection ofstorage structure 122 c, to enable data flow from storage structure 102c. Read and path access logic 174 is also responsible for notifying thehost processor that it may provide additional ingress insert data whenstorage structure 122 c becomes empty.

Processor Interface—Ingress Side

Referring back to FIG. 6 again, wherein an embodiment of processorinterface 112 of FIG. 3 is illustrated. As illustrated, for theembodiment, for the ingress packet side, processor interface 112includes a number of ingress data read and write (R/W) registers, andtheir associated processor control slave logic 156, ingress divertedpacket unpacker and data formatter 158, and ingress insert data packerand SOP/EOP generation logic 160.

Ingress data R/W registers, and their associated processor control slavelogic 156 are employed to facilitate a host processor in retrieving theingress diverted packet data and providing the ingress insert packetdata. In response to a notice of the ingress diverted packet data beingready for a host processor to retrieve, the host processor generates theappropriate control signal for ingress diverted packet unpacker and dataformatter 158 through the associated processor control slave logic 156.Ingress diverted packet unpacker and data formatter 158 in response,generates the appropriate read enable signals for the ingress divertedpacket storage structure 122 b. Further, unpacker and data formatter 172reads the gap-compressed packet data and the associated SOP, EOP and badpacket indicator from storage structure 122 b, and “unpack” them forplacement onto the appropriate bit positions of the data bus. Theprocess continues until the EOP is encountered (i.e. the applicable EOPbit set).

In like manner, a host processor generates the appropriate controlsignal for ingress insert data packer and SOPIEOP generation 160 throughthe associated processor control slave logic 156. Ingress insert datapacker and SOP/EOP generation 160 in response, generates the appropriatewrite enable signals for the ingress insert storage structure 122 c.Further, data packer and SOP/EOP generation 160 writes the insert dataand the associated SOP, EOP and bad packet indicator bits into storagestructure 122 c in “packed” form, and the unpacked portions aresuccessively taken off the appropriate bit positions of the data bus.

Protocol Processor

FIG. 9 illustrates an exemplary application of the present invention.Illustrated in FIG. 9 is multi-protocol processor 200 incorporated withthe packet diversion and insertion teachings of the present invention,including packet flushing, for multiple datacom and telecom protocols.As illustrated, for the embodiment, multi-protocol processor 200includes system interface 204, network interface 206, intermediateinterface 208, media access control block 210, Ethernet 64/64 coder 212,Ethernet on SONET coder 214, point-to-point protocol (PPP) and highlevel data link control (HDLC) processor 216, HDLC Packet over SONETcoder 218, SONET path processor 220, SONET section and line processor222, and most importantly, buffering structure 100 of the presentinvention, coupled to each other as shown. Further, multi-protocolprocessor 200 includes control function unit and interfaces 307-309,Elements 204-222 are selectively employed in combination to service datatransmission and receipt in accordance with a selected one of a numberof frame based protocols, including frame based protocols encapsulatedwithin a synchronous protocol, as well as streaming and packet variantsof the synchronous protocol. In various embodiments, the protocolsinclude at least one each a datacom and a telecom protocol, allowingmulti-protocol processor 200 to support data trafficking spanning local,regional as well as wide area networks. In a presently preferredembodiment, multi-protocol processor 200 is implemented as a singleASIC.

More specifically, for the illustrated embodiment, the elements areemployed in combination to service data transmission and receipt asfollows: Protocols Elements Employed SONET Stream System Interface,SONET Section/Line Processor, Network Interface SONET Packet SystemInterface, SONET path processor, SONET Section/Line Processor, NetworkInterface Packet over System Interface, HDLC processor, HDLC SONET POScoder, SONET path processor, SONET Section/Line Processor, NetworkInterface Ethernet on System Interface, 10 GbE MAC, Ethernet on SONETSONET coder, SONET path processor, SONET Section/Line Processor, NetworkInterface 10 GbE WAN System Interface, 10 GbE MAC, Ethernet 64/66 coder,SONET path processor, SONET Section/Line Processor, Network Interface 10GbE LAN System Interface, 10 GbE MAC, Ethernet 64/66 coder, NetworkInterface MAC Frame System Interface, 10 GbE MAC, Intermediate InterfaceHDLC Frame System Interface, HDLC Processor, Intermediate Interface

As those skilled in the art would appreciate, the concurrent support ofthese protocols in a dynamically selectable manner, in particular, theinclusion of 10 Gb Ethernet and Packet over SONET protocols,advantageously enables the processor to scale local, regional, and widearea networks.

For the illustrated embodiment, the “operating” protocol is specified tocontrol function unit 308, which in turn controls the above enumeratedelements accordingly. In a preferred variant of the illustratedembodiment, control function unit 308 includes a control register (notshown) having a 3-bit “protocol” field. The 3-bit “Protocol” field isaccessible via 3 corresponding pins (not shown) of processor interface307.

System interface 204 is provided to facilitate input of egress data andoutput of ingress data. In one embodiment, system interface 204 is a16-bit parallel LVDS packet interface, compliant with OIF's SPI-4interface defined for OIF-SPI4-02.0, which is a “phase 2” interface forthe communication of packetized data between a physical layer and linklayer entity. In one implementation, the 16-bit differential transmitand receive data busses operate at speed up to 832 Mb/s per bus line. Byvirtual of the ability of multi-protocol processor 200 to support theafore enumerated protocols, the transmit and receive data (i.e. theegress and ingress data) may be MAC, IP, PPP, HDLC or SONETframed/streaming data (including their in-band control words, whereapplicable).

10GbE MAC block 210 is provided to perform data link sub-layer mediaaccess control processing on egress and ingress MAC and IP data. Foregress data, 10GbE MAC block 210 accepts correctly formatted frames(minus the preamble or start frame delimiter), and in response, addingthe appropriate preamble/start frame delimiter, padding the frames tothe maximum frame size, calculating and inserting the appropriate framecheck sequences.

Ethernet 64/66 coder 212 and Ethernet on SONET Coder 214 are provided toperform physical sub-layer 64/66 and Ethernet on SONET coding anddecoding for the egress and ingress MAC and IP data respectively.

PPP/HDLC processor 216 is provided to perform data link sub-layerpoint-to-point protocol and high level data link control processing onPPP and HDLC data. PPP/HDLC processor 216 is employed to frame orde-frame IP and POS data, providing appropriate encapsulation orde-encapsulation, in accordance to PPP and HDLC. Similarly, HDLC POScoder 218 is provided to perform physical sub-layer Packet on SONETcoding and decoding for the egress and ingress HDLC data respectively.

SONET path processor 220 is provided to perform path processing for“packetized” SONET data, whereas SONET section and line processor 222 isprovided to perform section and line processing for “packetized” as wellas “streaming” SONET data.

Network interface 206 is provided to facilitate output of egress dataand input of ingress data. In one embodiment, correspondingly, Networkinterface 206 is a 16-bit LVDS interface compliant with OIF's SFI-4interface. In one embodiment, it operates at 622 MHz (645 for Ethernet64/66 encoded data). Similar to system interface 204, by virtue of theability of processor 100 to support the various protocols the egress andingress data may be physically coded MAC, IP, PPP, HDLC or SONETframed/streaming data (including their in-band control words, whereapplicable). The coded data may be a SONET data stream encapsulating thehigher-layer protocols or a 64/66 coded Ethernet stream.

Intermediate interface 208 on the other hand is provided to facilitateoutput of MAC or HDLC egress data and input of MAC or HDLC ingress data.In one embodiment, parallel interface 208 is a 32-bit SSTL-2 interface.In one embodiment, parallel interface 208 operates at 312.5 MHz.

Multi-protocol processor 200 is the subject matter of co-pendingapplication entitled “A Multi-Protocol Processor With Data TrafficSupport Spanning Local, Regional and Wide Area Networks”, having atleast partial common inventorship and filed May 18, 2001. The co-pendingapplication is hereby fully incorporated by reference.

Optical Networking Module

FIG. 10 illustrates a further exemplary application of the presentinvention. Illustrated in FIG. 10 is integrated optical networkingmodule 300 incorporated with multi-protocol processor 200 of FIG. 9,which as described earlier is incorporated with the packet diversion andinsertion teachings of the present invention. Optical networking module300 includes optical components 302, optical-electrical components 304,support control electronics 305, and multi-protocol processor 200 ofFIG. 9, coupled to each other as shown. As described earlier,multi-protocol processor 200 includes in particular, a number ofinterfaces and processing units, collectively referenced as referencenumber 310, control function unit 308, processor interface 307 andutility interface 309 coupled to each other and components 302-304 asshown.

Optical components 302 are employed to facilitate the sending andreceiving of optical signals encoded with data transmitted in accordancewith a selected one of a plurality of protocols known in the art.Optical-electrical components 304 are employed to encode the egress dataonto the optical signals, and decode the encoded ingress data. Asdescribed earlier, in a presently preferred embodiment, the supporteddatacom and telecom protocols include but are not limited to SONET/SDH,10Gbase-LR, 10Gbase-LW, Ethernet on SONET, Packet on SONET, and soforth. Support control electronics 305 are employed to facilitatemanagement of the various aspects of optical components 302 andoptical-electrical components 304. As described earlier, multi-protocolprocessor 200 is employed to perform data link and physical sub-layerprocessing on the egress and ingress data in accordance with a selectedone of a plurality of supported datacom/telecom protocols, and tofacilitate management of the multi-protocol processor 200 itself andoptical, optical-electrical components 302 and 304 (through supportcontrol electronics 305).

In a presently preferred embodiment, optical components 302,optical-electrical components 304, support control electronics 305 andmulti-protocol processor ASIC 200 are encased in a body (not shown)forming a singular optical networking module, with provided softwareforming a singular control interface for all functionality. That is, inaddition to being equipped to provide optical to electrical andelectrical to optical conversions, clock and data recovery, and soforth, integrated optical networking module 300 is also equipped toprovide data link and physical sub-layer processing on egress andingress data selectively for a number of protocols.

Further, in the preferred embodiment, control function unit 308 alsoincludes control features, i.e. control registers and the like (notshown), in conjunction with support control electronics 305 to support anumber of control functions for managing optical components 302,optical-electrical components 304 as well as multi-process protocol ASIC200. Processor interface 307 is employed to facilitate provision ofcontrol specifications to control function unit 308, whereas utilityinterface 309 (a digital interface) is employed to facilitate managementof components 302 and 304 by control function unit 308 (by way ofsupport control electronics 305). The complementary control functionsare placed with an embedded processor of optical networking equipmentemploying integrated optical network module 300. That is, integratedoptical networking module 300 advantageously presents a singular unifiedsoftware interface to optical networking equipment designers anddevelopers to manage configuration and operation of the optical andelectrical components, as well as protocol processing. As those skilledin the art would appreciate, as a result, the complexity of designingoptical networking equipment, such as optical-electrical routers,switches, and the like, is reduced.

Optical networking module 300 is the subject matter of co-pendingapplication entitled “Optical Networking Module”, having at leastpartial common inventorship and filed May 18, 2001. The co-pendingapplication is hereby fully incorporated by reference.

Conclusion and Epilogue

Thus, it can be seen from the above descriptions, a novel packetdiversion and insertion approach, including packet flushing, that ismore scalable and suitable for modern high speed networking, inparticular, for efficient network trafficking that spans local,regional, and wide area networks in support of multiple datacom andtelecom protocols has been described. While the present invention hasbeen described in terms of the foregoing embodiments, those skilled inthe art will recognize that the invention is not limited to theseembodiments. The present invention may be practiced with modificationand alteration within the spirit and scope of the appended claims. Thus,the description is to be regarded as illustrative instead of restrictiveon the present invention.

1-59. (canceled) 60-68. (canceled) 69-75. (canceled)
 76. A bufferingstructure comprising: at least a first FIFO storage structure coupled toa system-side interface at an input end and to a network interface at anoutput end and being adapted to stage undiverted ones of egress packets;at least a second FIFO storage structure coupled to a system-sideinterface and being adapted to stage diverted ones of egress packets; atleast a third FIFO storage structure coupled to a network interface andbeing adapted to stage insertion ones of egress packets; first writepacket drop logic coupled to the at least first FIFO storage structureand being adapted to perform tail flushes of the at least first FIFOstorage structure; second write packet drop logic coupled to the atleast second FIFO storage structure and being adapted to perform tailflushes of the at least second FIFO storage structure; and first readpacket drop logic coupled to the at least first FIFO storage structureand being adapted to perform head flushes of the at least first FIFOstorage structure.
 77. The buffering structure of claim 76, wherein saidbuffering structure further comprises: at least a fourth FIFO storagestructure coupled to the network interface at one end and to thesystem-side interface at another end and being adapted to stageundiverted ones of ingress packets; at least a fifth FIFO storagestructure coupled to the network interface and being adapted to stagediverted ones of ingress packets; third write packet drop logic coupledto the at least fourth FIFO storage structure and being adapted toperform tail flushes of the at least fourth FIFO storage structure; andfourth write packet drop logic coupled to the at least fifth FIFOstorage structure and being adapted to perform tail flushes of the atleast fifth FIFO storage structure.
 78. The buffering structure of claim76, wherein said buffering structure further comprises: at least afourth FIFO storage structure coupled to the network interface at oneend and to the system-side interface at another end and being adapted tostage undiverted ones of ingress packets; third write packet drop logiccoupled to the at least fourth FIFO storage structure and being adaptedto perform tail flushes of the at least fourth FIFO storage structure;and second read packet drop logic coupled to the at least fourth FIFOstorage structure and being adapted to perform head flushes of the atleast fourth FIFO storage structure.
 79. A buffering structurecomprising: at least a first FIFO storage structure coupled to a networkinterface at an input end and to a system-side interface at an outputend and being adapted to stage undiverted ones of ingress packets; atleast a second FIFO storage structure coupled to a network interface andbeing adapted to stage diverted ones of ingress packets; at least athird FIFO storage structure coupled to a system-side interface andbeing adapted to stage insertion ones of ingress packets; first writepacket drop logic coupled to the at least first FIFO storage structureand being adapted to perform tail flushes of the at least first FIFOstorage structure; second write packet drop logic coupled to the atleast second FIFO storage structure and being adapted to perform tailflushes of the at least second FIFO storage structure; and first readpacket drop logic coupled to the at least first FIFO storage structureand being adapted to perform head flushes of the at least first FIFOstorage structure.
 80. The buffering structure of claim 79, wherein saidbuffering structure further comprises: at least a fourth FIFO storagestructure coupled to the system-side interface at one end and to thenetwork interface at another end and adapted to stage undiverted ones ofegress packets; at least a fifth FIFO storage structure coupled to thesystem-side interface and adapted to stage diverted ones of egresspackets; third write packet drop logic coupled to the at least fourthFIFO storage structure and adapted to perform tail flushes of the atleast fourth FIFO storage structure; and fourth write packet drop logiccoupled to the at least fifth FIFO storage structure and adapted toperform tail flushes of the at least fifth FIFO storage structure. 81.The buffering structure of claim 80, wherein said buffering structurefurther comprises: at least a fourth FIFO storage structure coupled tothe system-side interface at one end and to the network interface atanother end and adapted to stage undiverted ones of egress packets;third write packet drop logic coupled to the at least fourth FIFOstorage structure and adapted to perform tail flushes of the at leastfourth FIFO storage structure; and second read packet drop logic coupledto the at least fourth FIFO storage structure and adapted to performhead flushes of the at least fourth FIFO storage structure.